As the number of information sources in organizations are growing, it is becoming increasingly difficult for consumers of the information to access it in a logical and structured way that relates to the traditional business objects they find familiar within their organizations (e.g., customers, assets, vendors, staff, etc). Data from existing systems is typically made available in a very technical way that requires significant technical and development skills to surface it to non-technical users in the organization. Non-technical users need to be able to add information within a logical business object definition without involving technical or development skills. Both technical and non-technical users of data need to be able to access their information from multiple data/information sources in a structured business object like way, while still maintaining the flexibility to add additional information definitions to the existing business objects or to create new business objects from existing or new data sources without the need for complex solution development.
Existing Enterprise Application Integration (EAI) systems combined with development tools can be used to custom develop solutions which make data and information more accessible, but these solutions are typically hard-coded and require significant technical and development skill to maintain and change over time. In addition, information workers are limited by the static business forms and information presented to them by the solution applications or custom developed applications they use on a day to day basis. Still further, existing process automation tools do not provide the necessary level of modeling tools and concepts to allow both technical and non-technical users to author a completed business process solution in a single modeling/automation tooling environment.
These problems can be solved by using Enterprise Application Integration (EAI) sources (e.g., EAI software, Web Services, Application API) to provide a higher level framework (e.g., runtime broker and adapter services) with relating solution components (e.g., user interfaces and tooling) which empowers technical and non-technical users to author logical business objects which includes data definitions (e.g., customer name, surname, etc.) and actions or methods (e.g., save, load, delete) from existing or new data sources. Users can combine data from multiple sources into one single business object definition, including data and method/actions definitions. The logical business object is a smart object that exposes a single logical data structure and view of the business object as well as a single set of logical methods that are associated with the business object. The business object is dynamic, and its definition can be changed by either adding or removing data or actions without the need to involve technical or development resources to reconfigure or recompile the actual business objects.
However, once a dynamic business object has been created, it cannot be easily accessed and consumed by remote client devices. Today's technologies require that before the business object can be consumed through existing web service technologies, an endpoint must be defined. An endpoint is used to specify the interaction requirements between the client device and the business object. For example, the client device sends a message to the business object's endpoint when it wants to use the business object, and the message is formatted according to information specified by the endpoint. A business object may have multiple endpoints that allow different ways for clients to consume that business object.
Typically, an endpoint is defined by an address, a binding, and a contract. An address is the location where the endpoint resides. A binding specifies how a business object can be consumed, such as, for example, protocol or encoding information. A contract for each object lists the operations exposed by the business object. All of this information must be specified before a business object can be used by a remote client device.
This approach presents several problems. The contract must be manually generated for each object. Because the endpoint includes the contract, the endpoint is also manually generated for each object. Manual generation of a contract (and thus the endpoint) can be expensive and time-consuming and is susceptible to user error. Further, the endpoint can become stale if it is not updated as soon as the business object is updated and the user may rely on endpoint information that does not accurately represent the business object.
Accordingly, there is a need in the art for a more efficient, cost-effective, and accurate way to allow client devices to access and consume remote business objects.